Making this calculation faster is great! I'm just wondering if renaming lamports_per_byte_year to lamports_per_byte and changing the values might be confusing for people grepping for lamports_per_byte_year.

If we were going to keep the current concept of rent long-term I would agree, but as rent is going away anyway I wonder if this would add more short-term confusion?

If the goal of this SIMD is to remove the floating point operations from this calculation, I wonder if it would be simpler to mark exemption_threshold as deprecated and make the following change in the SDK to remove the floating-point calculation:

    /// Minimum balance due for rent-exemption of a given account data size.
    pub fn minimum_balance(&self, data_len: usize) -> u64 {
        let bytes = data_len as u64;
        // exemption_threshold has been deprecated and is always 2
        let exemption_threshold = 2;
        ((ACCOUNT_STORAGE_OVERHEAD + bytes) * self.lamports_per_byte_year) * exemption_threshold
    }

Thoughts? That said, I am ok with the proposed change, just wanted to throw a simpler alternative out there.

Yes, this was one of the discussed alternatives above. If we simply decide "This number is now 2 forever, we promise not to change it", it has the least moving parts. It doesn't require a feature gate either. We can simply change all our libraries to ignore the f64 value stored in the Rent account/sysvar and substitute with our own u64. The main downsides are that we waste 1 extra CU multiplying by 2 every time unnecessarily, and instead of removing existing protocol crust, we introduce a new piece where we have this random number 2 thrown in there for no reason. I prefer changing the value to 1 to remove it from the equation, but both are fine changes imo.

Another idea. What if we were to just hardcode the value of rent in our libraries too? Then it should be possible to determine rent calculation statically, avoiding needing a syscall (another 100 CUs saved) or rent account (15 or so CUs saved if you use pinocchio) at all. If the idea is that we want a stop gap before eventually removing it entirely, I would think that's an even better solution than hardcoding the 2. If we have to support rent long-term, changing the value still makes the most sense to me.

If we simply decide "This number is now 2 forever, we promise not to change it", it has the least moving parts. It doesn't require a feature gate either. We can simply change all our libraries to ignore the f64 value stored in the Rent account/sysvar and substitute with our own u64.

I would prefer this option, but I am happy with either.

What if we were to just hardcode the value of rent in our libraries too?

Do you mean making the minimum balance independent of the size of the account? I think that we should still take the size of the account into consideration.

No, I mean making the lamports per bytes for rent exemption static. Right now, the reason we have a syscall and/or Rent account at all is to tell us:

1. how many lamports_per_byte_year we are paying, which is multiplied by
2. the exemption_threshold of 2.0f64 years

If these values will not change between now and when Rent is removed altogether, we could simply hardcode both values into our libraries enabling you to statically derive the correct amount of rent to pay without invoking a syscall at all.